Pair Programming just wastes resources…

This is a reaction I've encountered when discussing the practice with managers and engineers alike. After all, it seems counterintuitive: two engineers handling the same task, with one not even typing!

First off, the notion of calling human beings "resources" makes me cringe. But more importantly, this statement is simply untrue. Here's why:

📚 Knowledge transfer: language features, architecture, application structure, keyboard shortcuts, tools, and much more
✅ Continuous peer review leading to higher quality and better team alignment
🔁 Mutual benefits, regardless of seniority levels
💡 Thought-provoking collaboration generating new insights
⏰ Flexible duration—from quick 5-minute sessions to multiple hours (with breaks, of course!)
⌛ Reduced or eliminated dedicated review time
🧦 Built-in four-eyes principle, supporting SOX separation of duties requirements

Pair programming is inherently agile. It aligns well with the Agile Manifesto's principle:
🧑‍🤝‍🧑 Individuals and Interactions over Processes and Tools 🛠️

It also embodies the principle that states:
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

However, pair programming isn't for everyone. Give it a try, and if you find it's not for you or you're not in the mood, speak up. Conversely, if you're enthusiastic about pairing, remember not to force others to participate.

What are your thoughts on pairing? Is it a waste of time or an agile and useful way of working?

What about working in a remote setup?

Let's discuss!

Please let's discuss on LinkedIn.